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A SOLUTION TO THE RACE CONDITION IN THE ICP 


In NWG/RFC #143 a race condition in the ICP was described and a 
solution was suggested. The problem arises because the Host-—Host 
protocol does not specify what the NCP should do when it gets more 
than one request of STR (or RTS) to the same socket. As a result 
this decision depends on the particular implementation: some may 
queue these requests (SDC for example), some will refuse a request if 
the socket is already connected (UCLA for example), etc. 


The solution is not to change the Host-Host protocol, but finda 
third level ICP which does not depend on this issue. Such a solution 
is the following: the INITs from server to user and user to server 
((S5), (S6), (U5), (U6) on page 3 in RFC #143) should use another 


socket -- say U+2 and U+3. The sequences in RFC #143 would be: 
Server User 
(S1) LISTEN (L, 32) (U1) INIT(U,L, 32) 
(S2) [wait for match] (U2) 
(S3) SEND (L,S) (U3) RECEIVE (U,S) 
(S4) CLOSE (L) (U4) CLOSE (U) 
(S5) INIT(S,U+3,Bu) (U5) INIT (U+3,S,Bu) 
(S6) INIT(S+1,U+2,Bs) (U6) INIT (U+2,S+1,Bs) 


This solution will solve the problems pointed out in RFC #143 without 
any assumptions made about the NCP implementation. The solution in RFC 
#143 assumes that the NCP can notify a process when a command (e.g., 
close) comes in, which is implementation dependent. 
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